Subject: Explorer FSM updates

From: "Steve Klein" <[email-masked]>
Date: Fri, 9 Sep 94 08:50:32 EDT

Reference: Note from Paul Brittain dated Fri, 2 Sep 94 12:37:23 BST

Here are my comments on Paul's comments on my comments on Paul's
explorer FSM.  My comments are marked with SCK>>>.  Any other comments
are welcome and encouraged.

Steve

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Paul's note:
------------
Steve,

I agree with your updates to the Explorer FSM I posted a while back, with the
following exception:

DLC_RESOLVE_C and DLC_RESOLVE_R seem like bad choices for the new DLC
action/event as we already have an event/action (respectively) of the same name.
How about DLC_RESOLVE for the action and DLC_RESOLVED for the event?

SCK>>> The reason I chose these names was because DLC_XID and DLC_DGRM
SCK>>> are both events and actions.  Your names are probably better.
SCK>>> It seems easier to keep things straight when you can talk about
SCK>>> an event or action with having to qualify it as such.

Appended below is an updated FSM that reflects these changes and can be used as
the basis for input to Alan if the group agrees.  I have also included the other
updates that would be required to merge this with v0.12 of the spec.  please
post any comments on these suggested changes.

Note that I have NOT posted this direct to Alan to give the group a chance to
discuss it first - and he wouldn't accept it from me anyway as it is a FSM
change!

I have posted replies to your other mails separately so that this one stays
fairly clean and clear.

See you in Raleigh,

Paul Brittain
Data Connection.

PROPOSED CHANGE TO EXPLORER FSM IN DLSw 0.12:
=============================================
               .
               .
SCK>>> Everything up to section 7.4 looks good.
               .
               .
>>Add a new section 7.4 with the following text:

7.4     Explorer Traffic

SCK>>> After going through these FSMs I realized that there are really
SCK>>> be two explorer FSMs, one for NETBIOS names and one for Data Link
SCK>>> IDs (MAC/SAPS).  For NETBIOS names there would be one FSM instance
SCK>>> for each unique combination of Source Name, Destination Name,
SCK>>> Data2 field and Response Correlator.  For Data Link IDs (SNA for
SCK>>> now) there would be one FSM instance for each unique
SCK>>> combination of Target MAC, Target SAP, Origin MAC and Origin SAP.
SCK>>> What do the rest of you think?

The CANUREACH_ex, ICANREACH_ex, NETBIOS_NQ_ex, and NETBIOS_NR_ex SSP
messages explore the topology of the DLSw cloud and the networks attached to
it.  These explorer frames are used to determine the DLSw partners
through which a MAC or NetBIOS name can be accessed.  This information may
optionally be cached to reduce explorer traffic in the DLSw cloud.

If a DLSw is aware from cached information that a given MAC address or NetBIOS
name is accessible through a given partner DLSw, it should direct all circuit
setup attempts to that partner.  If the circuit setup fails, or no such data is
available in the MAC or name cache database, the DLSw may fallback to issuing
the setup attempt to all DLSw partners on the assumption that the cached data
is now out of date.  The mechanism for determining when to use such a fallback
is implementation defined.

DLSW implementations may also use a local MAC cache to enable responses
to CANUREACH_ex requests to be issued without the need for TEST frame exchange
(or equivalent) until the CANUREACH_cs is received.  Again, the fallback
mechanism for determining when such local cache data is out-of-date is
implementation defined.

The use of either cache is an optional function in DLSw.  An implementation may
choose to always issue explorer frames or to use either or both types of cache.

The following sections describe the FSM used for explorer frames.  The DLC
events and actions are a subset of those described in section 7.2 for the main
circuit FSM.  The states in the explorer FSM are as follows:

     State Name            Description
     ----------            -----------
     RESET                 The initial state.
     SENT_EX               Local DLSw has issued an explorer message
     RECEIVED_EX           Local DLSw has received an explorer message
     SENT_REC_EX           An explorer frame has been both sent and received for
                           the same (potential) NetBIOS circuit.

7.4.1    RESET State

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive CANUREACH_ex | If replying from    | If DLC_RESOLVE sent, |
    |                      | cache, send         |   RECEIVED_EX        |
    |                      | ICANREACH_ex        |                      |
    |                      | else if allowed to  |                      |
    |                      | test availability,  |                      |
    |                      | issue DLC_RESOLVE.  |                      |
    |                      | Optionally update   |                      |
    |                      | cache.              |                      |
    +----------------------+---------------------+----------------------+
    | Receive ICANREACH_ex | Optionally update   | RESET                |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX          |
    |                      | Optionally update   |                      |
    |                      | cache.              |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex| Optionally update   | RESET                |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_RESOLVE_C        | Send CANUREACH_ex   | SENT_EX              |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_EX              |
    +----------------------+---------------------+----------------------+

7.4.2    SENT_EX State

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive ICANREACH_ex | DLC_RESOLVE_R       | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RECOG)| RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_RESOLVE_C        |                     | SENT_EX              |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_EX              |
    | (different local     | Optionally update   |                      |
    |  session number than | cache               |                      |
    |  existing searches)  |                     |                      |
    +----------------------+---------------------+----------------------+

An implementation may choose whether to handle circuit setup race conditions
SCK>>> Aren't we really talking about explorer crossover here?
either by using entirely separate FSM instances and simply allowing both ends
to issue TEST frames, or by detecting a reverse CANUREACH_ex frame here and
issuing an ICANREACH_ex message and DLC_RESOLVE_R action.

7.4.3    RECEIVED_EX State

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive CANUREACH_ex | Optionally update   | RECEIVED_EX          |
    |                      | cache               |                      |
SCK>>> Shouldn't we mention something here about keeping track of the
SCK>>> duplicate explorer.  A CANUREACH_ex received in this state means
SCK>>> a different DLSw partner has initiated an independent search.
SCK>>> When the DLC_RESOLVED comes back we would want to respond with
SCK>>> a ICANREACH_ex to both DLSw partners.
    +----------------------+---------------------+----------------------+
    | Receive ICANREACH_ex |                     | RECEIVED_EX          |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex|                     | RECEIVED_EX          |
    +----------------------+---------------------+----------------------+
    | DLC_RESOLVED         | Send ICANREACH_ex   | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_REC_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_RECOG)| Send NETBIOS_NR_ex  | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+

An implementation may choose whether to handle circuit setup race conditions
SCK>>> Aren't we really talking about explorer crossover here too?
either by using entirely separate FSM instances and simply allowing both ends
to issue TEST frames, or by detecting such a reverse DLC_RESOLVE_C event here
and issuing an ICANREACH_ex message and DLC_RESOLVE_R action.

7.4.4    SENT_REC_EX State

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RECOG)| RECEIVED_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_REC_EX          |
    | (different local     | Optionally update   |                      |
    |  session number than | cache               |                      |
    |  existing searches)  |                     |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_RECOG)| Send NETBIOS_NR_ex  | SENT_EX              |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+

This state is required if an implementation wishes to manage NQ/NR crossover
cases from a single FSM instance by detecting 'opposite' NAME_QUERY attempts
between the same two NetBIOS names.  If separate FSM instances are used instead,
this state is not required and the transitions to it from other states can be
removed.

7.4.5     NetBIOS Session Numbers

NetBIOS NAME_QUERY and NAME_RECOGNIZED frames exchange NetBIOS session numbers
between the end stations.  For correct NetBIOS operation over DLSw, it is
important that all SSP NETBIOS_NQ_ex frames received by a DLSw cause NetBIOS
NAME_QUERY frames to flow on the LAN with the new session number from the
NETBIOS_NQ_ex.  These frames cannot be replied to from a cache of locally
available NetBIOS names in the same way that MAC addresses and CANUREACH_ex
messages can be handled.
SCK>>> This is an important point to make.

Also, NAME_QUERY messages are normally retried several times on the LAN.
The generation and absorption of such frames is outside the scope of the FSM
defined above.

SCK>>> Gene Cox's note on NETBIOS retry absorption covers this.